Transactional Memory Should Be an Implementation Technique, Not a Programming Interface

© Transactional Memory Should Be an Implementation Technique, Not a Programming Interface Hans-J. Boehm HP Laboratories HPL-2009-45 transactional memory, locks Transactional memory is often advocated as an easier-to-use replacement or locks that avoids any possibility of deadlock. Recently, as more care has been exercised in precisely specifying its semantics, a number of researchers have observed that probably the most attractive semantics for transactional memory systems is based on "single global lock atomicity", i.e. on the semantics of a single global lock. We argue that this should be taken one step further: The synchronization operations seen by the programmer should really just be locks, possibly with some syntactic sugar for easier programming with a single global lock. Use as a deadlock-free lock replacement does not require any rollback primitive, or any other constructs that expose properties of the implementation. And it appears that such extensions add considerable complexity. External Posting Date: February 21, 2009 [Fulltext] Approved for External Publication Internal Posting Date: February 21, 2009 [Fulltext] Copyright 2009 Hewlett-Packard Development Company, L.P. Transactional Memory Should Be an Implementation Technique, Not a Programming Interface This will appear as a position paper in the USENIX HOTPAR ’09 workshop. Hans-J. Boehm HP Laboratories